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ABSTRACT 

The desire to integrate newly available, graphically— oriented CASE (Computer Aided 
Software Engineering) tools with existing software design approaches is changing the 
way PDL is used for large system development. In the approach documented here, 
Software Engineers use graphics tools to model the problem and to describe high level 
software design in diagrams. An Ada— based PDL is used to document low level design. 
Some results are provided along with an analysis for each of three smaller GE Ada 
development projects that utilized variations on this approach. Finally some 
considerations are identified for larger scale implementation. 


BACKGROUND 

In 1987, the Ada Core Team was formed within GE’s Military & Data Systems Operation to 
apply advanced technologies including the Ada language to the development of large 
satellite ground systems that form our business base. GE M&DSO has been producing 
real time satellite ground stations for 15 years with a strong, established methodology. 
The addition of graphics workstations and graphics tools to this methodology is just a 
natural evolution of these methods. The techniques proposed here have grown out of 
GE’s methodology and been refined through use on various Ada projects and IR&D work. 
The information in this paper is based primarily on the results of these efforts. 
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INTRODUCTION 

The availability of automated graphic tools sup- 
porting structured analysis and structured design 
techniques, and the need for major improvements 
in productivity and quality are causing software or- 
ganizations to rethink their software engineering 
methodologies. PDL (Program Design Language 
or Process Description Language) is the most 
commonly used design tool in many organizations. 
As a result there is a wide base of experience in 
PDL as a descriptive medium. 

Yet, when an organization wants to add CASE 
(Computer Aided Software Engineering) tools to 
their existing methodology, it often is unclear what 
role PDL should play. Are PDL and graphic 
CASE tools redundant, or can they both contrib- 
ute to modern software design practices? And 
what about the practice of coding some Ada con- 
structs (notably package specifications) during 
detailed an even preliminary design? Does this 
narrow the scope of PDL’s usefulness? 

This paper is intended to document our analysis 
of the most effective tools for each portion of the 
software design cycle. Each tool, graphics, PDL, 
and Ada source code, has characteristics that 
make it useful to apply to part of the design prob- 
lem. PDL has been used in the past for the 
representation of many design aspects. Today 
there are areas where PDL is best suited, and ar- 
eas where other tools are better suited than PDL. 

By way of further introduction, let us examine the 
traditional design approach and use of PDL. 


TRADITIONAL APPROACH TO 
SOFTWARE DESIGN 

Traditional documentation of a program with PDL 
involves two parts. The primary part is the proc- 
ess description, which is a description of the 
implementation or algorithm used in a program/ 
subprogram, process, function or procedure. The 
second part is the prologue, which is usually pre- 
sent to support the process description by 
explaining input/output data items and local vari- 
ables. The prologue often provides references to 
the design or requirements documentation, and 
usually includes information and format necessary 
to an automated PDL processor. Sometimes the 
term PDL is used to refer to just the process de- 
scription, and others it is used to refer to the 
prologue as well. In this paper PDL will be used 
to refer either to the process description and to 
the language used for process description. 
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Software Design Phases 

The evolution of a software design occurs in dis- 
tinct steps over several project phases. During the 
Software Requirements Analysis phase, a soft- 
ware system is partitioned into Computer Software 
Configuration Items (CSCIs), and all software sys- 
tem requirements are allocated among these 
CSCIs. 

During the Preliminary Design phase, a high 
level design is conceived for each CSCI sufficient 
to satisfy its allocated requirements. This design is 
described in English in a continuous, flowing, 
’easy to read' paragraph format. Software hierar- 
chy charts are usually prepared next for the 
design review. Database and file format designs 
are initiated during this phase to reflect attributes 
of the preliminary design. 

The software design process continues during the 
Detailed Design phase with the generation of pre- 
liminary software source modules for each design 
component. The method to be used in these 
modules is described using a PDL process descrip- 
tion. The first ’cut’ at this description would 
likely be at a high level of abstraction (showing 
fewer details). Iterative refinements are then 
made of the PDL process description, assisted 
somewhat by the use of structure charts. The de- 
sign is refined by adding more detail on how the 
module’s functionality is to be provided. This 
lengthens the process description, and separate, 
subordinate modules are then created to break 
out cohesive elements of this process description. 
A PDL processor is used during this activity to 
check for syntax errors and to create calling trees 
and object/variable cross-references for analysis 
use. 

The end of the PDL refinement process is 
reached when two criteria are felt to be satisfied. 
The first requires that the process descriptions 
should be detailed enough that the module can be 
coded by someone familiar with the technology 
but unfamiliar with the design. The second crite- 
ria requires that process descriptions must be of a 
suitable length (between 1 and 2 printed pages) to 
result in reasonably sized code modules. Consis- 
tency and quality are encouraged by the 
establishment of PDL standards, by the informal 
sharing of sample PDL, and by peer review or 
structured walk— through of the PDL processor 
printed output. 

The Coding phase implements the design. The 
source code is written into the same modules al- 
ready containing the prologues and PDL process 
descriptions. In some cases the source code is 


interspersed throughout the PDL in a style that 
explains a step of conceptual processing with a 
block of PDL, then implements it with a block of 
source code. In other cases the entire process 
description is kept intact at the beginning of the 
module, followed by the entire source code. The 
former makes it easier to match PDL to source 
code, while the latter allows the PDL (and the 
source code) to be better seen and understood in 
whole. 

Benefits Of Traditional Approach 

Our Software Development section has enjoyed 
steady productivity gains since this PDL methodol- 
ogy was adopted. PDL usage has resulted in 
higher quality and greater productivity than previ- 
ous development methods (which made use of, 
among other things, English prose descriptions 
and flowcharts). Of course, many factors are at 
work in increasing productivity including the avail- 
ability of more and better hardware, but at least 
some of this improvement can be attributed to the 
use of a vigorous, robust, well-known and well- 
followed methodology. The use of PDL 
contributes to quality and productivity in the fol- 
lowing ways: 

1) Creation and maintenance of documen- 
tation is easier when employing the same 
tools ( e.g computer terminals, editors) 
used in writing the source code. 

2) Design descriptions are more complete, 
rigorous, detailed, and more standard- 
ized. 

3) Design walkthroughs may be used more 
readily to reduce the number of design 
errors. 

4) Some aspects of the design (e.g., syn- 
tax, keyword balancing, call trees, 
indexing of references) may be checked 
automatically. 

5) Deliverable documentation may be pro- 
duced automatically from source code 
containing PDL. 

6) Fewer errors are made when represent- 
ing actual software implementation due 
to the proximity of PDL and source 
code. 

7) Less effort must be spent on explanatory 
comments when the PDL is located with 
the source code. 


Disadvantages Of Traditional Approach 

Usage of this approach has also shown some dis- 
advantages. Some of these are: 

1) The 'easy to read’ English prose used in 
preliminary design documentation is 
hard to write in a way that is free from 
ambiguity. 

2) The PDL documentation for a large sys- 
tem is copious and very low— level in 
detail; it can be very difficult to find the 
PDL associated with a given aspect of 
system behavior. 

3) PDL does not support well the more 
formalized structured approaches to par- 
titioning (e.g., analyzing coupling and 
cohesion) and automated checking, es- 
pecially when experts try to review the 
partitioning decisions of others or when 
automated tools are used to verify the 
design. 

4) PDL approaches traditionally have ne- 
glected the data part of a design 

Advantages of Newer Graphic Tools 

CASE tools now available automate graphically- 
oriented regimens in system analysis and software 
design. These tools include support for such ap- 
proaches as Data Flow and Control Flow 
Diagrams, Structure Charts, Entity Relationship 
Diagrams, Object Dependency Diagrams, Object 
Interrelationship Diagrams, Data Dictionaries and 
integrated tool databases. GE has used the 
team work® tool from Cadre Technologies, Inc. 
for the studies described in this paper. 

The automated graphic tool approach to Struc- 
tured Analysis and Structured Design has many 
commonly recognized benefits: 

1) Communication via graphics seems to 
occur at a much higher information 
bandwidth, using visible relationships 
and psychological cues to more quickly 
attain a high level of reader understand- 
ing. 

2) Graphics seem to provide better support 
in decomposing or partitioning a soft- 
ware problem or design, and in 
examining alternatives and reviewing the 
results. 

3) Production of graphics for formal pres- 
entations and reviews is automated. 
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4) Tools can often assist in the storage, 
control of and access to information by 
design teams. 

5) Tools can provide higher levels of auto- 
mated balance and consistency checking 
by including a data dictionary, and in 
some cases can automate design verifica- 
tion. 

6) Graphic tools seem to better represent 
system level behavior, interface design, 
and data design. 

Disadvantages of Graphical Tools 

Graphics CASE tools also have their disadvan- 
tages, including: 

1) Graphics are generally less effective than 
PDL when dealing with larger quantities 
of low level details (for example, flow 
charts become considerably less attrac- 
tive when used to document low level 
details of very large programs) 

2) Newer, more complicated approaches 
may require much more extensive tool 
and methodology training to be success- 
ful. 

3) Graphics CASE tools can involve a sub- 
stantial additional investment in both 
hardware and software. 

4) Development schedules must be adjusted 
to reflect additional time spent on the 
front-end design. 

5) It is very difficult to prove ( e.g to cus- 
tomer or business management) that the 
additional time and money spent up 
front results in cost savings later. 

6) Human nature sometimes leads people 
to believe that the tool will do the work 
for you; really it just helps to represent 
work you do yourself. 

PROPOSED METHODOLOGY 

The following methodology, documented in our 
Software Development Plan, has been synthesised 
from our existing methodology and from proposals 
by many authorities. It has been adapted to com- 
plement our existing approach and is recommend 
by our group for GE’s large development con- 
tracts. The phases here are much the same as in 
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other approaches, including the classical waterfall 
approach and the default cycle documented in 
DoD— STD— 2 167A. Familiar activities occur 

during the phases but more effective tools, refine- 
ment techniques and documentation media are 
used. 

The basic approach uses graphics at the higher 
levels of abstraction and PDL at lower levels. 
This documented approachsupports the use of the 
Ada language well. A non-Ada version of the 
Software Development Plan is planned to properly 
exploit this same methodology on non-Ada pro- 
jects. The current Plan version makes use of 
object-oriented terms and methods. However, it 
is intended to support either object-oriented or 
functional decomposition of a system, or an ap- 
proach that hybridizes the two. 

Approach By Phase 

The Software Requirements Analysis activity 
uses a basic Structured Analysis approach (as de- 
scribed by Yourdon & DeMarco, McMenamin & 
Palmer, Ward & Meller, Hatley & Pirbhai, and 
others) including the use of Data Flow and Con- 
trol Flow Diagrams and a Data Dictionary for 
Essential and Incarnation models (see the refer- 
ences). The purpose of this is to model the 
problem in more detail in order to understand it. 
This is done first in a way that removes the con- 
sideration of technology from the statement of the 
problem solution, and then adds it back into con- 
sideration. The results of this analysis, in the 
form of Data Flow Diagrams, are input to the next 
phase of software development. 

Preliminary Design involves the identification of 
Configuration Software Components (CSCs) from 
the Data Flow Diagrams. These may be high- 
level objects and operations identified in an 
Object-Oriented approach. Object Dependency 
Diagrams are produced for the identified objects. 
Interfaces between CSCs (and CSC Is if not done 
during Requirements Analysis) are defined, then 
depicted using package specifications. The pack- 
age specifications are coded in Ada, showing the 
Ada declaration of each resource (mostly types 
and subprograms) exported from the package 
specification, along with Ada with clauses showing 
necessary dependencies. Compiling these inter- 
face specifications checks for consistency and 
makes a firmer foundation for further breakdown 
of development work. High-Level executive 
CSCs are described with PDL at this stage to show 
the major elements of control. The PDL for the 
executives would include the creation of their dec- 
larations in package specifications or as 
stand-alone subprograms, along with Ada with 



clauses for their dependencies. The PDL consists 
of structured language process descriptions based 
on the Ada executable statements for iteration, 
loops, and conditionals. No attempt is made to 
compile the executives at this point, the purpose is 
to describe control dependencies inherent in the 
design. This PDL may in fact be contained solely 
within the CASE tool and not within a source 
code member at all. This makes it instantly acces- 
sible when documenting and refining later stages 
of the design. 

The design process continues during the Detailed 
Design phase as structure charts are generated for 
each CSC. These show the architectural details 
involved in implementing the CSC. Computer 
Software Units (CSUs) are identified. These may 
be lower level objects in an object-oriented sys- 
tem. The implementation of individual CSUs are 
described in PDL process descriptions within the 
CASE tool graphics environment. This gives the 
programmer a better sense of partitioning and of 
the overall system structure than does writing the 
PDL into a disconnected source file. No compila- 
tion is attempted of these process descriptions. 
They are based on the Ada language syntax for 
universality of understanding, not for compilability 
at this stage. However, new interfaces derived at 
this detailed level of design (i.e., more package 
specifications) are coded in Ada and checked 
with the compiler. These package specifications 
declare all types and data structures necessary to 
components external to the package specification. 
Also, within the package bodies, internal types 
and major internal data structures are coded in 
Ada and compiled. This helps to firm the data 
design and package dependencies. This is a ma- 
jor design component that is best described and 
checked with the Ada language and compiler it- 
self. 

The Coding phase that follows detailed design in- 
volves transfering the PDL from the CASE tool 
into existing and new Ada source modules, then 
writing Ada code for the design represented in the 
PDL process descriptions. 

TRIAL PROJECTS 

A number of GE Ada projects have been under- 
taken using variations on the traditional and 
proposed methodologies. The following projects 
have been selected to present some variety in ap- 
proaches to PDL. No hard metrics are available 
for these projects to give insight into the contribu- 
tion of methodology components, such as the 
number of errors created and found during a 


phase, or even created but not discovered. In- 
stead, project team members were interviewed 
about problems, rework and errors that occurred. 
Their comments were then analyzed for apparent 
relation to the choice of methodology. 

The projects described here are IR&D projects 
that have occurred over the last two years at GE. 
They appear here in chronological order, and in 
fact show an evolution in methodology over this 
time period. Methodology refinement was not the 
primary intention of these IR&Ds, each one was 
instead performed with what seemed the best ap- 
proach to those directing the efforts at the time. 
Methodologies of later projects were of course 
tuned to benefit from the lessons of the earlier 
ones. Most participants were first time Ada pro- 
grammers, although each project (after the first) 
had at least one person assisting during coding 
that had benefitted from some experience on a 
previous phase. The experienced people were not 
usually available during the design phase, how- 
ever. 

Project 1 

One study in Ada software development involved 
the redesign and re-implementation of a predic- 
tive mathematical simulator. The project resulted 
in approximately 8000 compiled Ada statements 
(counted by semicolons, not including blank or 
commented lines). Automated CASE tools were 
not available during the study. Diagrams were 
produced using a PC-based general-purpose 
drawing tool. The Ada compiler itself was used to 
check the PDL for syntax. PDL consisted of 
coded and compiled Ada block constructs (e.g. 
loops, conditionals), compiled type and variable 
declarations, and Ada comments instead of pro- 
cedural (sequential) statements. 

During Preliminary Design, narrative English 
specifications were produced according to more 
traditional development methodology. Object/ 
Package Dependency Diagrams and Control Flow 
Diagrams were drawn. These were presented dur- 
ing the Preliminary Design Review (held at the 
end of the Preliminary Design Phase), but effort 
was not spent to maintain these diagrams for use 
during Detailed Design. High-level objects and 
procedures were identified and package specifica- 
tions coded (but not compiled— the development 
environment was not available at the time). 

During Detailed Design, the Ada package specifi- 
cations were entered and compiled. Any 
interface errors detected then were corrected. 
Package bodies, subprograms and most types and 
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variables were declared in compiled Ada within 
the code modules. 

In the Coding phase, the unimplemented (com- 
mented) portions of the compiled PDL bodies 
were coded and the components integrated and 
debugged. 

The study was a quite a success as far as Ada soft- 
ware development was concerned. However, an 
analysis is possible of problems that arose during 
the study for possible effects of the choice of 
methodology. For instance, there was a wide vari- 
ation among the six programmers participating in 
the study in the style and composition of the com- 
piled Ada PDL. Some felt very comfortable 
during Detailed Design writing almost complete 
Ada code and very few PDL comments. Some 
felt very uncomfortable with the Ada syntax and 
compiler and wrote mostly comments and few 
compiled types/objects/block constructs. This 
sometimes resulted in inconsistent levels of ab- 
straction of the PDL design description. 

In general, the project tended to achieve different 
levels of abstraction and maturity at different 
times. It took longer for a programmer to write 
PDL that was mostly code. It took less time to 
write PDL that was mostly comments, but more 
time to write the source code in the next phase. 
Management misunderstandings resulted from this 
when attempting to assess the progress of the ef- 
fort at a given point in time. 

The problem with different styles of PDL and dif- 
ferent PDL/code contents appears to be more 
common with projects that use an Ada compiler 
to check PDL. This also seems to occur more 
frequently when there is less experience with Ada 
and the PDL approach. One remedy for this is 
more and better training. Another is not to use 
the Ada compiler to check PDL syntax — and the 
problem goes away if a PDL processor is used 
which has a more forgiving syntax, or if only a 
visual check is performed on the PDL. The visual 
check is appropriate only if module sizes are kept 
small. After all, PDL syntax errors are only dam- 
aging if they cause ambiguity or incorrect 
interpretation in the design. 

The problem with inconsistent levels of PDL ab- 
straction that showed up on this project is 
common to many different approaches and proc- 
essors. This is bad because it is confusing, it 
makes the design less understandable and less 
easily checked by others. Abstraction is useful 
because it hides those details unnecessary to this 
portion of the problem solution. The more local- 
ized the scope of detail, the less affected the 
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system will be if it changes. Each person (or com- 
ponent of software) has to be an expert in fewer 
areas, and is free to concentrate and come up 
with a better, more pure solution in his/her/its 
own area. Removing unnecessary detail makes a 
system design more understandable, modifiable 
and robust. 

The consistency problem decreases with program- 
mer experience. Levels of abstraction can also be 
checked for consistency during peer review or 
structured walkthrough, giving feedback to the 
programmer and allowing the descriptions to be 
corrected. The best level of abstraction for a PDL 
process description of a given module is some- 
where above (less detailed than) the level at which 
the source code for that module would need to be 
written. 

Despite the apparent problems the team was able, 
however, to bring all portions of the system to 
completion by the end of the test phase. The pro- 
ductivity of the total effort was only very slightly 
lower (a few percent) than that of the more tradi- 
tional projects. This was probably affected by a 
variety of factors including less effective training, 
lack of tools and technical difficulties with the 
platforms used, but also that slightly less docu- 
mentation was produced than is normal. 

Project 2 

The second project for analysis was a 1988 IR&D 
effort to design and implement a platform-inde- 
pendent Ada binding for a Man-Machine 
Interface. Portions of the project made use of the 
graphic CASE tool when it was available. It used 
an Ada based, uncompiled PDL but no PDL 
processor. This project resulted in a larger design 
than was implemented, with about 2000 lines of 
compiled Ada code (again by semicolons, not in- 
cluding blank or commented lines) being 
produced. 

During Requirements Analysis, Data Flow Dia- 
grams were constructed to describe physical, 
logical, and incarnation models. The resultant 
diagrams were used during Preliminary Design to 
help identify high-level objects and to partition 
the system. Ada package specifications and their 
bodies were written (with subprograms deferred) 
and compiled to document the interfaces. Object 
Dependency Diagrams were drawn to show the 
object relationships. 

During Detailed Design, extensive use was made 
of the Ada compiler. Drivers were identified and 
coded in Ada. Important type and object decla- 
rations were coded within the package bodies. A 



key routine in each of the major objects/packages 
was coded and tested to ensure the feasibility of 
the design. A key routine was some subprogram 
that, when demonstrated, would validate most of 
the design decisions for the rest of the subpro- 
grams in an Ada package. Other, non-key 
subprogram bodies were designed and docu- 
mented only in PDL within the source modules. 
This PDL used Ada syntax but was commented 
and not compiled. Some type and data declara- 
tions were coded compiled. Some structured 
design diagrams were constructed but not many. 
The burden of design documentation and analysis 
and refinement was performed using compiled 
package specifications, compiled key routines , and 
PDLed subprograms. The CASE tool was not 
continually available during this phase due activi- 
ties involving the tool evaluation and purchasing 
mechanism. 

During the Coding phase the subprograms already 
expressed in PDL were expanded to code. The 
coded portion of the system was integrated, tested 
and demonstrated. 

Again, the overall project was successful but some 
useful methodological refinements may be sug- 
gested from observation. One such observation is 
that because the graphic CASE tool was not al- 
ways available during the project, a graphics 
approach was not taken during much of the pre- 
liminary and detailed design stages. Instead, 
emphasis was placed very early on representing 
the design with coding package specifications and 
bodies. Much rework was involved as new alter- 
native designs were identified, coded in Ada 
package specifications and bodies, reviewed, then 
modified. The normally constructive and neces- 
sarily iterative process of conceiving a solution, 
expressing it, evaluating it, and suggesting other 
alternatives suddenly seemed to involve too much 
effort and be too destructive to the participants. 

One possible approach to this difficulty of rework 
involves exploring the design in more detail, using 
graphics and PDL within the CASE tool, before 
package specifications are coded. The tool has 
fairly good support for this. Balancing is checked, 
and creation and modification of graphics is made 
easy within a window — and — mouse oriented envi- 
ronment. The tool checks balancing and graphic 
relationship rules for the resulting diagrams. 
Then, when the Ada package specifications are 
coded and compiled, they are built on a founda- 
tion of previous work which has already involved 
consideration of many of the possible alternatives. 
There should be less need for generating alterna- 
tives. 


Overall, the productivity of this project met that of 
other projects in our organization’s past. 

Project 3 

The third project was the most recent and the 
most closely matched to the proposed methodol- 
ogy. The late— 1988 project completed the coding 
and testing phase during the writing of this paper. 

It redesigned and coded two CSCs (functions) of 
a prototype real-time distributed ground system in 
Ada. Over 7000 lines of Ada code (measured by 
the same criteria as in the other projects) were 
written. Extensive use of the graphic CASE tool 
was made throughout the entire design effort. 
Again, an automated PDL processor was not 
used. 

During the Software Requirements Analysis 
phase, the system was modeled in Data Flow Dia- 
grams. During Preliminary Design, these DFDs 
were used to generate Objects and Operations, 
and Object Interrelationship Diagrams were drawn 
using the CASE tool. Major objects were coded 
as Ada package specifications, with their opera- 
tions being the subprograms exported from the 
package specification. 

During Detailed Design, Structure Charts were 
drawn showing the interrelationships of each ob- 
jects operations in performing some component of 
the system’s purpose. Each operation was de- 
scribed with Ada— based PDL within the confines 
of the CASE tool. Refinement was performed by 
editing the PDL to increase the detail, then break- 
ing out pieces of this new detail into new software 
components and creating new modules for them 
in the structure chart. When analysis and review 
of the structure charts and PDL met with satisfac- 
tory results, matching Ada package specs were 
created. Each specification was coded to show 
the exported resource (mostly types and subpro- 
grams) and the procedures stubbed out. PDL 
prologues were placed in the Ada modules, but no 
PDL. The PDL remained within the CASE tool 
database retrievable through the structure charts. 

During the Coding phase, the subprograms were 
written in Ada either from the PDL printed from 
the CASE tool, or from the same PDL cut and 
pasted into the modules through the window and 
mouse-oriented workstation environment. The 
design information remained available within the 
CASE tool database (and would be delivered that 
way, in a soft copy documentation scheme for de- 
liverable software). 

This approach seems to have paid off in a number 
of ways. Partitioning seems to have been so fully 
explored using the CASE tool that little rework of 
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compiled Ada package specifications was neces- 
sary. Design alternatives were efficiently analyzed 
within the CASE tool, where graphic and PDL in- 
formation combined to give a good view of the 
system at several different levels of abstraction. 

Module sizes were judged to be excellent: a half 
page maximum of PDL. Quite a few modules 
tested correctly when first compiled, even when 
coded from PDL by a first— time Ada program- 
mer. This was attributed to the simplicity of the 
modules and the clarity of the PDL, which in itself 
might be attributed to the quality of partitioning. 


The quality of the PDL seemed to be enhanced by 
its proximity to the graphic representation of the 
overall hierarchy, and the relative ease of tra- 
versal from PDL description to PDL description 
throughout the hierarchy. This ease of use con- 
tributed to good partitioning showing good 
coupling and cohesion characteristics. 

The productivity on this project seems to be well 
ahead of that established for traditional projects 
(in the ball park of a 10-20% improvement for a 
first Ada project). 



A view of PDL alternatives and our target approach 

Figure 1 


CONCLUSIONS AND SUGGESTIONS 

Choice of Representation 

One general theme in the methodology is to ex- 
plore a design fully given the tool appropriate to 
the level of abstraction. The choice of tool should 
efficiently allow representation of that level of ab- 
straction, and allow review, generation of 
alternatives, and easy representation of the final 
choice. Alternatives should be explored fully and 
adequately at the design stage under considera- 
tion, with the tool that does so in a most efficient 
(and reliable) manner. 

Graphics seem to be a useful, powerful, and effi- 
cient tool for upper to middle level design. They 
P. Usavage, Jr. 

GE 

8 of 23 


also, with the proper tool, serve as an outstanding 
mechanism for indexing or gaining access to the 
low level of design. A graphical tree structure 
with a system breakdown is more easily understan- 
dible and more efficient a representation when 
searching for a given piece of a system than any- 
thing that we’ve seen before. 

Quality and Testing 

The alternatives and final choice of design from a 
phase should be subjected to some form of testing , 
that is, analysis, review, compilation, balance 
checking, or whatever else can be done to find as 
many errors as possible and to demonstrate as 
much quality as can be demonstrated. This pro- 
vides a firmer foundation for the work that follows 
in development. As everyone knows, latent (un- 






discovered) errors output from a phase are much 
more expensive to fix in later stages. 

Scaling Up to Large Systems 

The methodology was designed from experience 
in large systems— for application on large systems. 
The one place where scaling will change emphasis 
is on the choice of and number of tools. No PDL 
processor was used at all for any of the examined 
projects. This was due to the size of the projects 
versus the cost of procuring a tool. This approach 
should be re-examined for a larger projects. 


On larger projects with more people it is more dif- 
ficult and more important to have consistent, 
quality PDL. A PDL processor can contribute to- 
ward this goal. It certainly doesn’t hurt to 
automatically check PDL for syntax and balancing 
errors, as long as the correction of errors does not 
detract from the creativity of design as sometimes 
happens with a strict Ada compiled PDL. No 
PDL processor is currently available that is inte- 
grated with the chosen CASE tool, but alternatives 
are being evaluated. 


P. Usavage, Jr. 

GE 

9 of 23 





THE VIEWGRAPH MATERIALS 


FOR THE 

P. USAVAGE, JR PRESENTATION FOLLOW 


FILMED 


Rtt E IQ . INTENTION AhUT BLANK 



A Modernized PDL Approach 
for Ada Software Development 


£ S 

QJ S 
wo H 

Cd _ 
;> <D 

5 fe 

O U 


3 

cd 

Plh 




s 


a> 
+- > 

C/3 

CZ5 

S3 

S3 




S 


a» 



Q 



P. Usavage, Jr. 
GE 

13 of 23 


etfUJL 


.INrtNIiCWAfcU BiAfl fi 



P. Usavage, Jr. 
GE 

14 of 23 


c n 

a 

o 





a 

JD 

3 

o 

Dh 

Oh 

D 

XP 

H 


C/5 

T3 

O 

4C 

V 

6 

'O 

g 

03 

C/5 

o 


g 

00 

o 1 

o 

'O X3 

O ^ 

C/5 

03 

X) 

I 

C/5 

O 

* r*H 

s: 

CD 
03 

5— i 
00 




X 

B 

a 

0) 

GO 
CO 

0) ^ 

g> s 

„ o 
00 
g 
o 

5-1 


CO 


CO 


q-n 

0) 

S' * 

x ^ 

C/5 4C 

’ , " H 4— > 

X ^ 

<D X3 


<D 

T5 

03 

S-H 

00 

cd 

5 


X3 

03 


G 
_o 
■(— > 
03 
■*— * 

G 

a) 


CD 
00 
o3 
G 
00 
G 
03 

G 'll 
oo eg 

a 31 

o> < 

CD 

XJ 

+-> 

<4-1 

O 


G 

o 

o 

T3 


X3 

< 

X) 


<N JQ 


P 8 

H <d 
CO X) 

1 JJ 


Q 

o 

A 

<D 

O 

P 

X3 

O 

5-h 

Oh 


<D 

4-> 

03 

o 

& 

o 

o 

G 


a 

o 

> 

cG 

W) 

• »-H 
+-> 
CO 

a) 

> 

a 

i— i 

D 

XG 

H 


G 

oo 

• r-H 

CO 

<D 

Q 

X3 

CD 

v-i 

G 

-»-> 

o 

G 

j— i 

■(— > 

CO 

C/5 

• 

CO 

1— < 
o3 
G 

< 

X3 

CD 

u 

P 

■*— < 

o 

a 

-t-> 

co 

Vh 

o 

C/5 <+H 


C/5 

X3 

o 

4C 


O 

O 

+-* 

W 

CO 

< 

u 

o 


o3 

O 


G 

O 

* i-H 
+-> 
o 

•s 

o 

J— < 

CD 


G 

<D 

a 

G 
o 
o 
a> 'o 

£ >-o 

(D 


03 

6 

o 


CO 

C 

o 

’J— > 

o3 

CO 

Vh 

o 

£ 


a 

V-H 

o 


C/5 

G 

O 

cd 

o 


o 

CD 

CD 

CZ) 


<D 
00 
o3 

G <D 

00 00 

G G 


<D 

G hJ 

I Q 


03 X 


o3 

CD 


X X 
CD CD 
o3 o3 

00 00 o3 4=1 


5*h 

CD 03 
CD 43 


_ 03 

Ph x) 

X3 <1 

CD _* 

C/5 X5 


X g 
00 T3 

< 


jD 

• r-H 

CD 

a 

o 

o 


a 

CD 


X3 

O 

Dh 

Cl, 

£ 

<D 

XG 

H 


o- 

C/3 

CO 

D 

O 

o 

Ch 

CG 

Ch 

OD 

• t-H 

co 

D 

T3 

D 

XG 


Dh 

ctf 

O. 

XG 

o 

• ?— H 

43 

£ 


'+-^> 

<>) 

3 

o 

4— > 

XG 

o 

• 1-H 

XG 


P. Usavage, Jr. 
GE 

15 of 23 





<D 

C /3 

03 

43 

Oh 

C /3 

* rH 

C/3 

13 

a 

< 

C /3 

4 -> 

a 

a> 

s 

<D 

J-h 

• 1 — I 

cr 

<D 


CO Vh 

X u 
>? 'S 

g o 
g 

< 

X 
a) 

j-i 

3 
+- > 
o 

Vh 

00 
X-H 

o 

CO 

+-> 

3 

CO 

<L> 

V-H 

a> 

iS 

3 

s 

g 

o 
o 

03 

G 
O 

X 

<D 

C/5 

G 
X) 

c 

WQ 
• *— < 

CO 

a; 

X 

<D 
G 
£ 


X 

G 

G 


CO 

6 

03 

Vh 

bO 

03 


£ 

o 

E 

G 

G 

Q 


(D 

h— > 
co 
>% 
co 

G 

* 

05 

O 

Oh 

a 

o 

o 

CD 

X 

G 

<d 

X 

£ 

a 

JD 

x 

o 

5-h 

Oh 


(X) 


<D 

G 


X 

• ?— < 
CO 


H-* 

G 


X 


CO 

G 

X 

G 

G 

<D 

1 v 

# o 

-4— » 

C/5 

o 

‘Oh 

*H-> 

03 

H-> 

5-h 

<D 

X 

(D 

G 

G 

X 

CD 

to 

<D 

G 


o 

to 

5-h 

H-» 

H— » 

G 

<L> 

Oh 

(D 

5-h 

to 

a 

E 




<D 

5-h 

"g 

G 

O 

♦ i-H 

X 

X 

cr 

Oh 


CD 

G 


X 

Vh 

wo 

b 


C /3 

<u 

C /3 

03 

4 =! 

CO 

a 

0 £> 

• 

C/D 

<D 

Q 

73 

a> 


03 

aj 

Q 

73 

a 

03 

Vh 

03 

G 


<D 

Vh 

fin 


S-H 

03 

X 
o 

<D 

5—i 

G 

H— > 

o 

2 

w 

CO 

O 

• ?-H 

x 

Oh 
o3 

G bb 
G 

* i-H 

X 


X 
Q 

Ph 

XI 
G 


CO 

O 

• l-H 

X 

Oh 
03 

Vh 

W) co 


X 3 

<D 

h— > 

aj 

Vh 

W) 

<L) 

G 

• 1-H 

X! 


£ 

O 

X 

G 


O 

O 

H-* 

w 

co 


X 

«> U 


G 

<d 

to 

<D 

V-i 

Oh , 
<D t-1 


O 

J-H 


Q 

Ph 


G 

WO 
C /5 X 

a> 

Q X 


<D 

X 

O 

o 

03 

X 

< 

X 

<D 


5-h 

<D 

X 

H— I > 

<D 

txO 

o 

H— » 

X 

Q 

X 

X 

G 

03 

C/5 

O 

• »-H 

Dh 

o3 

Vh 

bO 

w 

CO 

C 

c 3 

OD 

03 


& u 
5 E 


o 

O 


X 

<D 

H— » 

G 

<U 

to 

CD 

Vh 

Oh 

<D 

5-h 

to 

O 

o 

03 

<4— ( 

Vh 

<D 


5-h 

O 

4-h 

Vh 

CD 

Oh 

H— » 

G 

<D 

a 

CD 

G 

X 

CD 

5-h 

4) 

> 

■ j—H 
+-> 
o3 

Vh 

<L> 


Preliminary & As-Built design documents automatically produced 
Graphics high level design diagram serves as index to PDL 
pr ties together small PDL descriptions into big design picture 
Tool maintains design database for shared use 
Innovative approach with necessary stability for large systems 




ift 


0 *-£ 
S B 
E £ 

<D <D 


CT 1 Oh 
Q u 

u O 
TD C+H 

S "O 

<3 <L) 


T) S 

rO 


C/} -I— > 

Oh <3 


o cd 

£ 'tU 
o 55 
+-* 

9^ C 


_, <D 
T3 > 

<D <D 
•*— » ,— » 

C I 

U rO 


0 'O 

1 -8 

x> ° 

o o 


, £2 0 

t— ] O <D 

P g J 

Oh +75 <D 

a c 00 

T3 O 

< £ ° 

"0 o ,£ 

i> o c 

& £ 6 

e a 

§ | 

O .^H O 

Jl a o 

^ E 


P. Usavagc. Jr. 
GE 

17 of 23 



C/3 

<D 

c/3 

o 

Oh 


<D 

c/3 

O 

T3 

<D 

4-> 

• r-H 

S 

• r-H 

i-j 


o 

S-h 


Dh 

O 

Oh 

O 

o 

• i-H 

> 

'4— > 
« 
0/ 

c/3 

<D 

Gh 

Oh 

Dh 

o 

q-H 

H— > 

c/3 

O 


c/3 

O 

• i-H 

43 

Oh 

03 

Vh 

OX) 


<d 

■*— * 
03 

^H 

03 

CD 

a/ 

c/3 


O 

0 

H-* 

C 

• f— < 

£ 

03 

U 

T> 

a) 

Dw 17 —j 

>3 13 

1 Oh 

U o 

pin <p 

X! a> 

•ti 'O 

^ C/3 

03 


TJ 

CD 

H-> 

o 

s 

H-> 

C/1 

g 
o 
o 

c/i 

o 

-G g 
Oh g 

03 +-> 

*h Crt 

O 


CD 

TJ 

O 

O 

(D 

5-1 

<D 

£ 


<D 


c/i 

C/l 

CD 

O 

o 

03 

H— > 

o 

a 

(D 

<D 

£ 

C/3 

o 

• r-H 

.G 

CD 

o3 

S-h 

o 


o 

o 

H-< 

C/3 

• r-H 

C/0 

G 

o3 

60 

G 

• r-H 

G 

O 

• i-H 
4-> 

• rH 

G 

03 

CD 

<D 

> 

• i-H 

H-» 

O 

CD 

<H-H 

<+H 

(D 

-t— * 

O 

G 


J 

Q 

Oh 

'O 

• f-H 

Oh 

a 

o 

o 


<D 

a 

Dh 

O 

Dh 

<D 

Oh 

C/3 


03 

O 

03 

GxO 

a 

» ^H 

a 

o 


3 — 1 

03 

Oh 


s-h 

O 

«4-H 

H-H 

CD 


O 

S-i 


03 

JG 

£ 

<D 

a 

o 

C/3 

T3 
CD 
-»— * 
o 

o3 

S-h 

+-> 

(D 

T3 

C/3 

S — 1 

O 

H 

S-h 

<D 

X 

03 


G 
O 

• ^H 
H- > 

. o3 

G •£ 
g 

C/3 <D 


<H-H 

O 

G 

o 


c/3 

>3 o 


C/3 

CD 

s-h 

CD 

<D 


G 

CD 60 

-S CD 

o> c 

Gh o 

& ^ 
a g 

0 a 

<jD 


u 


G 

60 
* *-H 

C/0 

CD 

T3 


G 

<D 

C/3 

<D 

}—i 

CD 

CD 

H 


JD 

'Bh 

o 

<D 

CD 

<D 

6 

o 

C/3 

Vh 

O 


T3 

(D 

j> 

'o 

> 

G 

* i-H 

03 

h-> TU 

O < 

<H-h 

<H-h 

CD qj 

• I-H 

a o, 

L G 

X § 

w 8 


<D 

TD 

• t-H 

U 

CD 

T3 

G 

03 

C/3 

G 

60 

• r-H 

C/3 

(D 

T3 

CD 

> 

• ^H 

o3 

G 

j-i 

<D 

+-> 

"a 

-4— > 

G 

CD 

C/3 

CD 

S-h 

CD 

CD 

5— i 


G 

o 


T3 

<D 

S-H 

O 

a 


<D 

o3 


between them 

• Lower level design representation could obscure higher level 
tradeoffs 

Design alternatives took more time to work out than if 
quicker representation were available 
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Object Dependency Diagrams [Booch] used to analyze objects 

Structure Charts and Buhr Diagrams used for presentations but not 

for partitioning decisions 

PDL stored with Ada source code 

PDL processor not used 
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A MODERNIZED PDL APPROACH 
TO Ada SOFTWARE DEVELOPMENT 

Project 3 — Background 
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partitioning 

PDL stored within each process box in Structure Chart 
Structure Charts and PDL used to repeatedly analyze and refine 
software partitioning 
PDL processor not used 
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PDL processor (somewhat forgiving of syntax) is helpful to find true 
design errors 

ef should integrate with graphics CASE tool environment 




